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D.) Remarks 

Objections to the Claims: 

Claim 2 was objected to due to a mis-labeling of the claim elements. The clerical 
error has been corrected by suitable amendment of the claim. Withdrawal of the objection 
is respectfully requested. 

Clerical errors in Claims 9 and 14 have also been corrected. 

Objections to the Drawings: 

The drawings were objected to under 37 C.F.R. §1 .83(a) as not showing a feature 
corresponding to the claimed "said parallel array of protocol processors/' first referenced 
in Claim 21 . 

The present specification, at paragraph 49 in reference to Figure 3, states: 

. . . Multiple scalable arrays of data packet processors 58 can be directly 
connected to the switch fabrics 56 to provide various forms of protocol data 
processing , characterized as involving significant computation intensive 
operations. The individual data packet processors 58 may be configured to 
perform a single protocol conversion operation or multiple related operations. 
(Emphasis added.) 

Parallel arrays of "protocol processors" are also shown as data processors 58' in Figure 3 
and crypto processors 86 in Figure 4. 

Accordingly, the present specification does provide an appropriate description and 
further shows the claimed "said parallel array of protocol processors." Withdrawal of the 
objection is respectfully requested. 

Rejections under 35 U.S.C. §1 1 2: 

Claims 9, 1 4, and 1 5 were rejected under 35 U.S.C. § 1 1 2, 1 If, as failing to provide 
a written description of selecting a protocol processing function from a group of functions. 

The present specification, again at paragraph 49, describes the packet processors as 
permitting configuration "to perform a single protocol conversion operation or multiple 
related operations." Given that the operations specifically include the related, but 
complementary operations of encryption and decryption, the ability of the processors to 
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select among the available functions is absolutely clear to a person of ordinary skill in the 
art, if not inherent. 

In order to remove any possible adequacy of disclosure concern, the specification has 
been amended at paragraph 49 to recite ''to perform a single protocol conversion operation 
o r. by selection, any of multiple related operations." The substance of this amendment is 
inherently supported by the specification as filed and, further, is directly supported by at least 
the text of Claim 9, which is part of the original specification. The amendment therefore 
does not constitute new matter. 

Reconsideration of the rejection of Claims 9, 14, and 1 5 under 35 U.S.C. §112, l^H, 
is therefore respectfully requested. 

Claims 21 through 27 were rejected under 35 U.S.C. §112, V* H based on the 
alleged failure of the written description to provide support for the phrase "said parallel array 
of protocol processors." As established above, this phrase is fully supported by the text of 
paragraph 49 of the specification as filed. Reconsideration of the rejection of Claims 21 
through 27 under 35 U.S.C. §1 12, H, is therefore respectfully requested. 

Claims 2 and 8 through 15 were rejected under 35 U.S.C. §1 12, 2""^ H, as being 
indefinite. 

Claim 2 was asserted as being indefinite due to the use of the phrase "a like" (only 
Claim 2 contains this phrase). In context, the complete phrase is "a plurality of data protocol 
processors coupled to a like plurality of said first data ports of said data packet switch." The 
use of "a like plurality" in this manner is a long-standing, standard claiming practice well- 
accepted as indicating a definite "same as"-type relation. An issued claims search will 
demonstrate the wide prevalence of usage over the years; for example, see United States 
Patents 6,646,982, 5,747,870, 4,647,843 and 3,733,001. Furthermore, in the present 
instance, the ordinary meaning of the "a like plurality" language, when read in context, 
unquestionably means a plurality of the same number. Reconsideration of the rejection of 
Claim 2 under 35 U.S.C. §112, 2"^ H, is therefore respectfully requested. 

The phrase "the aggregate performance" is Claim 8 was asserted to lack antecedent 
basis. Claims 9 through 15 were rejected as dependent from the rejected Claim 8. 

Claim 8 is a method claim that uses the functional limitation "so as to enable 
utilization of the aggregate performance of said second processors" in qualifying the 
performance of the method step of "selectively distributing said predetermined network data 
packets to a plurality of second processors." 
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The claim clearly establishes that there are multiple second processors and that the 
processors each and together perform "o compute intensive data processing function." The 
second processors collectively have an inherent "aggregate performance" in "performing 
said compute intensive data processing function." This inherent quality is correctly referred 
to functionally as "the aggregate performance of said second processors in performing said 
compute intensive data processing function." 

Applicants' Attorney respectfully asserts that the functional qualification as presented 
is therefore clear, definite, and correct under the requirements of 35 U.S.C. §112, 2"^ H. 
Reconsideration of the rejection of Claims 8 through 15 is requested. 

Rejections under 35 U.S.C. §102: 

In order to establish a rejection under 35 U.S.C. §1 02, all elements of a claim must 
be identically found in a prior art reference. See, M.P.E.P. §706.02 (For anticipation under 
35 U.S.C. 102, the reference must teach every aspect of the claimed invention either 
explicitly or impliedly. Any feature not directly taught must be inherently present) (emphasis 
added); M.P.E.P. §2112 (In relying upon the theory of inherency, the Examiner must provide 
a basis in fact and/or technical reasoning to reasonably support the determination that the 
allegedly inherent characteristic necessarily flows from the teachings of the applied prior art. 
Ex parte Levy . 17USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) (emphasis in original); 
M.P.E.P. §2131. 

The essential nature of anticipatory identity requires that the function of the elements 
and their interconnections not just be colorably similar, but identical in all aspects. See, 
Richardson v. Suzuki Motor Co. . 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 
1 989) (The identical invention must be shown [by the reference] in as complete detail as is 
contained in the ... claim). Clearly, a prior art reference that discloses a collection of 
elements that are assembled differently and that function collectively in a different or 
incomplete way compared to the claimed invention is not an anticipating reference. 

Clai ms 1 — 6, 8, 10 — 13, 16 — 18, and 21 — 24 were rejected under 35 U.S.C. 
§1 02(e) as anticipated by Almulhem et al. (US Patent 6,587,431). 

In summary, Almulhem teaches nothing more relevant than a switch-fabric based 
router. Each functional node in the system identically implements just an ingress block 302, 
egress block 304, and a connecting switch-fabric. 

The rejected claims, in their different specific formulations, each require "data packet 
processors" (Claim 1), "data protocol processors" (Claims 2 and 3), "second processors" 
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(Claim 8), "protocol transformation processors" (Claim 16) and "protocol processors" 
(Claim 21). 

The Action indicates that these claimed protocol processors are shown in Almulhem, 
at col 7, Ins 10 - 44 and col 8, Ins 30 - 39. The indicated sections, however, describe 
nothing more than the ingress, egress, and switch-fabric management processors. These 
sections, at best, describe only ingress and egress processors that add conventional IP packet 
forwarding headers to all packets enable routing through the switch fabric; these processors 
do process data packets. The EPI processor 308 and other management processors only 
operate coordinate the routing operation between the ingress and egress processors (col 9, 
Ins 59 et seq); these processors do not process packets: they are not data packet processors. 

Thus, the ingress and egress processors of Almulhem correspond to, for example, the 
"network connection processors" of Claim 1 . The EPI processor corresponds to the control 
processor 84 described in the present specification. There are no remaining Almulhem 
processors that could correspond to the various "data packet processors" (Claim 1). That 
is, Almulhem simply does not show any additional "data packet processors [that] perform 
a data processing function over data contained within predetermined data packets" (Claim 
1). Almulhem similarly fails with regard to the remaining rejected claims. 

Therefore, Claims 1 -6, 8, 10-13, 16-18, and 21-24 are not anticipated under 
35 U.S.C. §1 02(e). Reconsideration of the rejection of these claims is respectfully requested. 

Rejections under 35 U.S.C. §103: 

Claims not identically shown by a reference otherwise available under 35 U.S.C. 
§1 02(a), (b), or (e) may be obvious under 35 U.S.C. §103. To establish a prima facie case 
of obviousness, three basic criteria must be met. First, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available to 
one of ordinary skill in the art, to modify the reference or to combine reference teachings. 
Second, there must be a reasonable expectation of success. Finally, the prior art reference 
(or references when combined) must teach or suggest all the claim limitations. The teaching 
or suggestion to make the claimed combination and the reasonable expectation of success 
must both be found in the prior art, not in applicant's disclosure . (Emphasis added.) In re 
Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). See also, M.P.E.P. §§2142, 
2143. 
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Claims 1 through 14: 

Claims 7, 9 and 14 were rejected under 35 U.S.C. §1 03(a) in view of 
Almulhem and Arrow et al. (US Patent 6,226,75 1 ). For purposes of completeness, Claims 
1 - 6, 8, and 10-13 will be considered as equally rejected under 35 U.S.C. §1 03(a). 

Almulhem essentially describes a multi-link router where identical IPF nodes support 
super-trunk transport of data packets between router end-points. Each node includes ingress 
and egress processors that connect to the switch-fabric, allowing bidirectional flow. An 
identically structured header is added to each packet that passes through the router to allow 
the route controller to manage load balancing distribution and correctly re-ordered delivery 
of the data packet stream. The header is added by the initially encountered ingress 
processor and stripped by the last egress processor. Thus, packets initially received by the 
Almulhem router are no different from the packets as finally delivered; the added packet 
headers are used internally only and the router does not effect any change on the payload 
data held by the underlying data packets. 

As explained by Almulhem, the issues of principal, if not exclusive, concern in 
. implementing the multi-link router are speed and ultimate delivery of data packets identically 
as originally received in terms of form and order. 

Arrow describes a VPN unit that is implemented as a software component. Each VPN 
component implements an encryption/decryption module and potentially other data 
processing modules. Individual VPN components are installed directly on client computer 
systems or installed as dedicated VPN units shared by multiple client computer systems. 

As taught by Arrow, VPN units 115, 126 in the shared configuration can be efficiently 
located on the outbound side of the local routers 114, 1 24 to take advantage of the data 
stream concentrating function of the routers. Placement on the inbound side of a router 1 34 
is achieved by routing proxy tunnels between the clients 131, 1 32 and router 1 34 through 
the VPN unit 1 35. The remaining alternative is to implement the VPN component directly on 
individual client computer systems. 

Motivation to Combine References 

The mere fact that references can be combined or modified does not render 
the resultant combination obvious unless the prior art also suggests the desirability of the 
combination. In re Mills , 916 F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990). 

Arrow itself is entirely silent as to any reason or need to place the VPN components 
in any other location or to suggest that there is any deficiency of any nature in the locations 
described. Arrow is entirely comfortable with available flexibility in locating the VPN 
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components where and as needed to support VPN connections between all computer 
systems. Almulhem is equally silent as to any reason or need to add any additional function 
of any nature to the multi-link router described. 

Arrow mentions the network use of routers and Almulhem acknowledges that the 
multi-link router must allow transmission of VPN packets. Neither reference provides any 
suggestion, explicit or implicit, of any possible benefit for combining any particular features 
of the other. Thus, the references themselves fail to provide any motivation to even consider 
combination. 

The Action proffers that a person of ordinary skijl in the art would have been 
motivated to combine the references ''because a strong encryption scheme can essentially 
guarantee privacy" and "utilizing compression formats requires less space than sending data 
uncompressed." 

While true in a generic sense, the proffered motivations are functionally irrelevant to 
why a person of ordinary skill in the art would consider combining these two specific 
references. That 'strong encryption promotes privacy' is simply a truism that motivates 
nothing more than having a VPN capability between some endpoints. That 'compression 
reduces bandwidth used' is an equally open truism. In the present instance, Arrow 
demonstrates that entirely secure and bandwidth efficient VPNs can be readily established 
wholly independent of their placement relative to routers and even entirely in the absence 
of routers. Almulhem demonstrates that very high-performance routers can be constructed 
and used without any need or limitation on the use of VPNs of any description. 

Given that a person of ordinary skill in the art knew of both routers and VPNs, the 
absence of any explicit or implicit suggestion to combine features instead indicates that such 
persons recognized substantive reasons for not combining. Specifically, the use of 
independent routers and VPNs provides a fundamental separation-of-concerns that, as so 
clearly demonstrated by Arrow, allows network systems to be flexibly architected. Such 
persons would have also have reasonably considered that implementing VPN components 
within super-trunk capable routers, such as Almulhem, fundamentally removes security far 
from the clients, thereby undesirably reducing the effectiveness of the VPN security. 
Furthermore, a security failure in a super-trunk capable router would present an 
unacceptable wide scope of exposure. Persons of ordinary skill in the art would instead 
consider a far more fine grained control over security to be desirable if not a requirement. 

Therefore, had a person of ordinary skill in the art even considered the combination 
proposed in the Action, the only truly credible motivation would have been to entirely reject 
the combination. A prima facie case of obviousness may be rebutted by showing that the 
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art, in any material respect, teaches away from the claimed invention. In re Geisler , 1 16 
F.3d 1465, 1471, 43 USPQ2d 1362, 1366 (Fed. Cir. 1997). 

Inability to Combine References 

Even beyond the lack of any credible motivation to combine, the references 
themselves fail to provide any indication of how, if at all, the teachings of the references 
could actually be combined. The relevant legal standard is clear: that "[t]he suggestion to 
combine may be found in explicit or implicit teachings within the references themselves, from 
the ordinary knowledge of those skilled in the art, or from the nature of the problem to be 
solved." WMS Gaming, Inc. v. International Game Tech. , 184 F.3d 1339, 1355, 51 
USPQ2d 1 385, 1 397 (Fed. Cir. 1 999). However, there still must be evidence that "a skilled 
artisan, confronted with the same problems as the inventor and with no knowledge of the 
claimed invention, would select the elements from the cited prior art references for 
combination in the manner claimed." In re Rouffet , 1 49 F.3d at 1 357, 47 USPQ2d at 1 456; 
see also In re Werner Kotzab , 217 F.3d 1365, 1371,55 USPQ2d 1313, 1317 (Fed. Cir. 
2000) ("[A] rejection cannot be predicated on the mere identification ... of individual 
components of claimed limitations. Rather, particular findings must be made as to the 
reason the skilled artisan, with no knowledge of the claimed invention, would have selected 
these components for combination in the manner claimed."). 

Even if given the suggestion to combine the references, a person of ordinary skill in 
the art would have no reasonable idea of where the VPN component could be installed 
within the Almulhem architecture. At best, since the Arrow system is taught as being a single 
connection device, the only configuration consistent with the teachings of the references 
would be to connect separate VPN units at either or both of the TCPIN 220 and TCPOUT 
232 ports of the Almulhem router. Such would likely accomplish nothing more than the 
existing behavior of the separate Arrow and Almulhem devices. 

If, instead, there was some suggestion to connect the VPN component somewhere 
internal to Almulhem, the references fail to provide any indication of where such a 
connection could be made. The VPN component, ds taught by Arrow, requires embedding 
in an operating system, Almulhem provides none. Even if a person of ordinary skill were 
to think of connecting a full VPN unit are to one of the internal IPF units or elsewhere 
internally, the ordinarily expected result would be a failure. The ordinary operation of the 
VPN unit would have the effect of wrapping of the Almulhem super-trunk control header 
under a VPN header, effectively securing the super-trunk control header. The necessary 
result, as would be quickly recognized by a person of ordinary skill, is the egress processors 
would be unable to process packets based on the encrypted headers. Thus, a person of 
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ordinary skill in the art would hove no expectation of success if a VPN unit were connected 
internal to Ainnulhem, 

Whatever nnodifications might be made to enable an actual combination of Arrow 
and Almulhem and achieve any working device are clearly beyond the ability of a person of 
ordinary skill in the art. Nothing in the references provides any indication of what those 
modifications might be or why any specific set be chosen to arrive at the claimed structures 
and methods. The Action as well provides no explanation of how or why a person of 
ordinary skill in the art would know to make any modifications to achieve any usable 
combination, let alone the specific claimed combinations. If a proposed modification would 
render the prior art invention being modified unsatisfactory for its intended purpose, then 
there is no suggestion or motivation to make the proposed modification. In re Gordon . 733 
F.2d 900, 221 USPQ 1 125 (Fed. Cir. 1984). 

Thus, while a theoretical combination of Almulhem and Arrow is easy to propose, in 
the present instance the proposal is nothing more than an improper use of hindsight based 
on a knowledge of Applicants' own disclosure. 

In contrast to the asserted references, the present invention, particularly as set forth 
in independent Claims 1,2,3, and 8, describes a data packet processing system generally 
characterized as providing a plurality of dedicated packet processors that are coupled 
through a switch-fabric to network processors that, in turn, interface to external network 
connections. The network processors route and load balance data packet streams directed 
through the switch fabric to the multiple data packet processors. The packet processing that 
might otherwise affect the ability of the network processors or the network at large to 
correctly route the data packets is performed by the data packet processors. To 
accommodate the compute intensive load to be handled by the packet processing 
processors, the claims expressly require connection of the data packet processors as a 
plurality fully accessible to the network processors through the internal switch-fabric. 

This structure and method of operation is directly reflected in the claim language of 
independent Claims 1, 2, 3, and 8: 

Claim 1 structurally requires a "plurality of data packet processors coupled through 
a data switch fabric between network connection processors." Thus, the data packet 
processors are connected on one side of the switch fabric. The network connection 
processors are connected to the other side and further function to provide connections to an 
external network. The data packet transfer path is therefore bidirectionally through the fabric 
between the network connection processors and the data packet processors. 
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Claim 2 structurally requires "a data packet switch" that provides separate data port 
connections to "a plurality of data protocol processors" and to "input and output data 
transfer processors." The data stream packet transfers between the protocol processors and 
the transfer processors are conducted bidirectionally through the switch-fabric. 

Claim 3 structurally requires "a switch providing data routing between input, output, 
and processing ports" to which are respectively connected "an array of protocol processors," 
"an input processor," and "an output processor." 

Claim 8 requires the steps of "receiving, by a first processor" data packets from a first 
network that are then internally routed by "selectively distributing said predetermined network 
data packets to a plurality of second processors" for compute intensive processing. The 
method then requires "collecting, by a third processor" and "transferring said converted 
network data packets to said second network." 

Consequently, these independent claims, and their dependencies, clearly require a 
structure and method of operation not taught or suggested by any proper combination of 
Almulhem and Arrow, even if credible motivation to consider combining the references 
existed. Accordingly, Applicants respectfully request reconsideration of the rejection of 
Claims 1 through 14. 

Claims 15 through 27: 

Claims 15, 19, 20, and 25 - 27 were rejected under 35 U.S.C. §1 03(a) in 
view of Booth, III et al. (US Patent 6,668,282) and either Almulhem or Almulhem and Arrow. 
For purposes of completeness, Claims 16-18, and 21-24 will be considered as equally 
rejected under 35 U.S.C. §1 03(a). 

The Booth reference describes use of a basic network packet encapsulation technique 
to enable a data packet to be round-tripped through a VPN tunnel implementing 
conventional IPsec encryption. The source computer system, simply identified as a first 
network element, requests VPN transfer of a data packet to a destination computer system 
terminating the VPN connection. The packet is encrypted and wrapped with a header 
identifying the terminal system. On receipt, the header is removed and the packet is 
decrypted for final delivery. The innovation described by Booth is that the final delivery IP 
address carried by the data packet is in fact that of the source computer system. Thus, the 
destination system blindly retransmits the data packet through the VPN connection to the 
source computer system for accounting. 

Other than demonstrating the conventional use of IPsec protocols, the Booth reference 
presents little of relevance to the structure and method of operating described in the rejected 
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claims. Booth does not disclose any additional or dedicated or connpute intensive packet 
data processor. Booth does not teach or suggest any need for additional, compute intensive 
data packet processors. Booth makes no notable mention of the use or presence of routers 
or the connection of any processors to any switch-fabric. 

Booth also provides no specifically applicable motivation to be combined with the 
other references. The asserted motivation, namely "a big advantage of IPsec is that security 
arrangements could be handled without requiring changes to individual user computers/' 
is questionable (or not understood) and, in any event, functionally irrelevant to specifically 
motivate any person to consider combining the teachings of these specific references. IPsec 
typically requires authentication of anyone or any computer system that attempts to make 
use of the protected VPN connection. Changing the location of the VPN connection point 
would not seem to make any difference to the required management or user burden. In any 
event, Booth does not teach or suggest, and the Action provides no explanation of any 
benefit to moving the location of a VPN connection point to any particular point, let alone 
one that would coincide with the placement of a router. Rather, a person of ordinary skill 
in the art would more likely consider combining a VPN with a router as reducing the flexibility 
of network configuration and undesirably moving the security afforded by a VPN connection 
further away from the users. 

Even if motivation were given. Booth and Almulhem, together or in further 
combination with Arrow, fail to teach or suggest using a plurality of dedicated data packet 
processors or, further, any way of incorporating such a plurality through an internal switch- 
fabric to perform compute intensive packet data stream processing with any expectation of 
success. The fact that IPsec protocols exist and can be used in the implementation of VPN 
connections, as taught by Booth, does not add any relevant teaching or suggestion as to how 
Almulhem could be combined with Arrow to realize the structure as specifically claimed in 
the independent base Claims 8, 1 6, and 2 1 . 

Similar to Claim 8 as detailed above, Claim 16 requires the steps of "receiving, 
through a first network connection" data packets from a first network and then internally 
"distributing said select network data packets to a plurality of protocol transformation 
processors." These protocol transformation processors collectively convert and provide 
"converted network data packets" that are then collected for "sending said converted 
network data packets through a second network connection," 

Claim 21 requires "a switch fabric implementing programmable channel transfer of 
data between first, second, and third fabric interface ports." An "ingress processor" and an 
"egress processor" are specified as connecting between networks connections and respective 
first and second fabric interface ports on the switch fabric. The third fabric interface ports 
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are connected to "a parallel array of protocol processors [that implement] a compute 
intensive network packet transformation function between said first and second protocol 
formats for data packets passed through said parallel array of protocol processors." 

The teachings of Almulhem, Arrow, and Booth, fairly considered, do not describe 
these specific structures or methods. Nothing in the references themselves, as viewed by a 
person of ordinary skill in the art, suggests or explains how multiple protocol processors 
could or should be configured relative to a switch fabric for any reason, let alone to 
efficiently provide a compute intensive packet processing function. 

Dependent Claim 1 5 and independent Claims 1 6 and 2 1 , and their dependents, are 
therefore not taught or suggested by any proper combination of Almulhem, Arrow and 
Booth, even if credible motivation to consider combining the references existed. Accordingly, 
Applicants respectfully request reconsideration of the rejection of Claims 15 through 27. 

Conclusion: 

In view of the above Amendments and Remarks, Applicants respectfully assert that 
Claims 1 through 27 are now properly in condition for allowance. The Examiner is 
respectfully requested to take action consistent therewith and pass this application on to 
issuance. The Examiner is respectfully requested to contact the Applicants' Attorney, at the 
telephone number provided below, in regard to any matter that the Examiner may identify 
that might be resolved through a teleconference with the Examiner. 



Respectfully submitted. 
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